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ABSTRACT 


This  thesis  addresses  a  known  problem  in  Carrier  Aviation.  The  problem  is  the 
constant  duplication  of  effort  writing  the  carrier  airplan.  This  problem  is  common  to  all 
airwings  and  results  in  late  airplan  publish  times  which  reduce  the  combat  effectiveness  of 
the  battlegroup.  The  analysis  of  the  airplan  is  accomplished  through  the  establishment  of 
a  database  of  carrier  airplans.  The  database  interacts  with  a  spreadsheet  designed  to  help 
Strike  Operations  aboard  the  carrier  streamline  the  process  of  writing  the  airplan. 

The  prototype  model  developed  accepts  inputs  from  the  Assistant  Strike  Operations 
Officer.  The  model  searches  the  database  for  airplans  that  conform  to  his  inputs  and 
provides  candidate  airplans  for  review.  Once  an  airplan  is  selected,  an  airplan  template,  in 
spreadsheet  format,  can  be  altered  to  meet  any  required  changes.  Once  changed  to  meet 
specific  tasking  the  final  product  can  be  saved.  After  a  period  of  operations  the  database 
search  file  can  be  updated  to  mold  the  database  to  a  specific  ship  and  airwing’s  standard 
operating  routine. 
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I.  INTRODUCTION 


A.  PROJECT  BACKGROUND 

This  Masters  Thesis  is  written  in  partial  response  to  a  Chief  of  Naval  Operations 
(OP-73)  Tactics  Development  and  Evaluation  (TAC  D  &  E)  proposal.  The  proposal 
addresses  a  known  problem  within  the  Aircraft  Carrier  Aviation  community  of  the  United 
States  Navy.  The  problem  is  inefficiency  in  the  daily  airplan  production  process.  In 
addition  to  the  duplication  of  effort  in  airplan  production,  late  publish  times  for  the 
airplan  have  repercussions  seen  throughout  the  ship,  airwing  and  accompanying 
battlegroup.  In  many  cases  the  individual  warfare  commanders,  such  as  the  air  warfare 
or  anti-submarine  warfare  commander,  are  not  embarked  on  the  aircraft  carrier.  They 
are  dependent  on  the  airplan  to  outline  the  aircraft  assets  they  will  have  at  their  disposal. 
The  overall  effect  of  the  airplan ’s  late  promulgation  is  lost  productivity  and  reduced 
combat  effectiveness  for  the  battlegroup. 

The  carrier  airplan  is  described  in  detail  in  following  sections  for  the  reader 
unfamiliar  with  carrier  operations.  The  most  basic  explanation  is  that  the  aiiplan  is  the 
single  approved  flight  schedule  for  the  whole  carrier  airwing.  Any  flights  originating 
and/or  terminating  aboard  the  aircraft  carrier  are  scheduled  via  the  airplan.  The  airplan 
directly  or  indirectly  affects  the  actions  of  every  person  aboard  the  aircraft  carrier  and, 
iii  most  cases,  every  ship  in  the  accompanying  battlegroup. 
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The  airplan  does  not  include  actual  names  of  aircrew  flying  each  sortie,  that  is  the 
responsibility  of  squadron  operations  departments.  The  airplan  provides  structure  for 
each  squadron’s  flight  schedule.  Publishing  the  airplan  late  forces  squadron  operations 
departments  to  hold  production  of  their  flight  schedules.  This  forces  similar  reduction 
in  combat  effectiveness  within  the  airwing. 

The  TAC  D  &  E  proposal  addresses  three  problem  areas.  The  first  area  is  analysis 
of  the  airplan  and  the  production  process.  This  portion  is  to  include  factors  which  have 
direct  and  indirect  affects  on  the  daily  airplan.  Second,  the  proposal  seeks  to  clarify 
which  of  these  factors  are  quantifiable,  if  any.  And,  fmally,  the  project  should  attempt 
to  automate  the  production  process.  The  proposal  suggests  a  prototype  model  to  be 
experimented  with  during  an  aircraft  carrier  workup  phase.  That  model  is  to  be  followed 
by  a  full-scale  working  model. 

B.  CARRIER  AVIATION  INTRODUCTION 

Aircraft  carrier  aviation  consists  of  several  facets  of  the  Navy  working  together. 
An  understanding  of  what  the  people  and  machines  do  and  how  they  interact  must  be 
established,  along  with  some  vocabulary  specific  to  carrier  aviation.  This  is  necessary 
to  comprehend  the  analysis  and  recommendations  to  follow. 

1.  Vocabulary 

•  Airplan:  The  single  approved  flight  schedule  for  the  embarked  airwing. 

•  Strike  Operations:  The  office  on  the  aircraft  ca-rier  that  composes  the  daily 
airplan.  The  ship’s  focal  point  for  all  airplan  information. 

•  Launch:  Take  off  from  aircraft  carrier. 
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•  Recover:  Land  on  the  aircraft  carrier. 


•  Recovery:  Actual  landing  of  a  group  aircraft. 

•  Cycle:  Period  between  successive  launches,  normally  between  one  and  two  hours. 

•  Event:  One  or  more  aircraft  launching  with  the  same  callsign. 

•  Flight:  A  group  of  two  or  more  aircraft. 

•  Turnaround  Time:  Time  needed  to  prepare  a  recovering  aircraft  for  later  launch. 

•  Deck:  Refers  to  the  flight  deck  of  the  aircraft  carrier  and  its  capability  to 
accomplish  flight  operations 

•  PIM:  Projected  Intended  Movement.  Course  and  speed  the  sl.'.p  must  make  over 
a  determined  period. 

•  Trap:  Landing  aboard  the  ship. 

•  Sortie:  A  mission  accomplished  by  a  single  aircraft  that  launches  and  recovers 
aboard  the  carrier. 

•  Night  Sortie:  A  sortie  that  recovers  at  night. 

2.  Aircraft  Carrier 

The  aircraft  carrier  is  organized  into  several  departments  that  accomplish 
various  tasks.  Each  of  the  following  departments  place  constraints  on  the  ability  of  the 
aircraft  carrier  to  conduct  flight  operations.  The  Operations  Department  is  responsible 
for  the  airplan.  The  actual  production  of  the  airplan  is  accomplished  by  Strike 
Operations  (STROPS)  which  is  part  of  the  Operations  Department.  The  Operations 
Department  gathers  inputs  from  other  departments  aboard  the  ship,  the  warfare 
commanders,  and  other  ships  in  the  battlegroup.  These  inputs,  along  with  standing 
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operating  orders,  or  battlegroup  commander  requirements,  form  the  structure  for  the  next 
day’s  airplan. 

There  are  two  basic  operating  situations  for  the  carrier  battlegroup; 
independent  battlegroup  operations  and  combined  command  support.  During  independent 
battlegroup  operations,  the  battlegroup  commander,  airwing  commander  and  the  carrier 
commanding  officer  set  the  tempo  of  operations  for  the  carrier  and  the  battlegroup.  The 
battlegroup  will  accomplish  training  to  maintain  full  combat  readiness.  For  the  airwing, 
these  training  requirements  are  outlined  in  the  COMNAVAIRPAC/COMNAVAIRLANT 
Joint  Training  Instruction  [Ref  1].  In  the  combined  command  support  role,  the  carrier 
battlegroup  commander  is  subordinate  to  a  fleet  or  combined  commander.  In  this  case, 
the  tempo  of  operations  is  set  by  the  combined  commander,  and  is  promulgated  through 
an  Air  Tasking  Order  (ATO).  In  either  case,  the  Operations  Department  formulates  the 
structure  for  the  next  day’s  airplan.  The  operating  pace  of  the  ship  and  airwing  is 
reduced  to  four  basic  variables: 

•  Number  of  day  cycles, 

•  Number  of  night  cycles, 

•  Total  number  of  sorties, 

•  Time  flight  operations  will  commence  and  secure. 

It  is  then  the  task  of  the  Assistant  Strike  Operations  Officer  (ASTKE)  to  meet 
all  standing  operating  orders,  ship  imposed  constraints,  and  any  other  known  operating 
limitations  while  composing  the  next  day’s  airplan.  These  constraints  and  limitations 
come  from  many  areas.  Air  Operations  (AIROPS),  another  division  of  the  Operations 
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Department,  functions  much  like  civilian  aviation  air  traffic  controllers.  AIROPS 
controls  the  airspace  within  fifty  nautical  miles  of  the  carrier.  They  impose  a  maximum 
number  of  sorties  allowed  for  any  given  recovery.  This  applies  mainly  at  night. 
Duties  also  include: 

•  Track  all  airborne  airwing  assets  within  fifty  miles  of  the  carrier. 

•  Maintain  location  data  on  all  other  airborne  tracks  within  fifty  miles  of  the  carrier. 

•  Maintain  status  board  of  all  airwing  assets. 

•  Control  airborne  tanking  procedures. 

•  Maintain  flight  following  radar  in  congested  areas. 

•  Maintain  status  of  aircraft  in  overhead  pattern. 

•  Provide  alternate  landing  field  information  to  aircraft  in  need. 

AIROPS  could  become  overwhelmed  if  too  many  aircraft  are  airborne.  In  this  way, 
AIROPS  constrains  the  airplan.  Too  many  airwing  sorties  airborne,  or  a  combination 
of  that  and  other  limiting  factors  can  severely  restrict  the  airplan  options. 

Other  departments  aboard  the  ship  also  impact  the  airplan.  The  flight  deck 
can  only  support  a  certain  number  of  sorties  for  any  given  cycle,  dependent  on  many 
factors.  The  Navigator  determines  the  course  and  speed  (PIM)  the  ship  must  make  to 
meet  scheduled  commitments.  Since  flight  operations  can  adversely  affect  the  ability  of 
the  ship  to  make  PIM,  this  can  constrain  the  airplan.  Other  constraints  are  planned 
evolutions  where  flight  operations  are  impossible,  such  as  underway  replenishment.  The 
ship’s  non-aviation  training  requirements  must  also  be  considered. 
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ASTKE  must  organize  all  the  inputs  from  the  Operations  Department  to 
compose  a  viable  airplan.  What  has  evolved  is  a  system  of  priorities.  Each  major 
contributor’s  input  to  the  airplan  is  prioritized,  and  the  requirements  are  met  within 
constraints.  Once  each  of  these  items  is  considered  the  airplan  is  written.  The  priorities 
are: 

•  Air  Tasking  Order  or  Battlegroup  Commander  Intentions. 

•  Warfare  Commanders’  Intentions. 

•  Ship’s  Training. 

•  Airwing  Training. 

The  approval  process  subjects  the  airplan  to  careful  scrutiny.  The  proposed 
airplan  is  initially  checked  by  ASTKE.  The  next  step  is  the  Strike  Operations  Officer. 
He  is  most  concerned  with  ships  training  and  ensuring  there  is  a  sufficient  number  of 
certain  missions  for  the  ship  to  maintain  special  qualifications.  Next,  the  airplan  must 
win  the  approval  of  the  Air  Operations  Officer.  He  ensures  the  airplan  can  be  flown 
safely.  His  considerations  include  the  number  of  aircraft  airborne  at  any  given  time  and 
the  ability  of  the  flight  deck  to  ready  aircraft  for  subsequent  launches.  The  approving 
signature  is  the  carrier  Operations  Officer.  His  focus  is  ensuring  an  overall  flyable 
airplan  and  that  all  standing  orders  and  tasking  have  been  met.  A  diagram  of  the  input 
and  approval  process  can  be  seen  in  Figure  1. 
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INPUTS 


Figure  1  Airplan  Approval  Process 
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3.  The  Airwing 

The  aircraft  carrier  notional  airwing  consists  of  a  mixture  of  multi-mission 
aircraft.  Table  1  shows  the  notional  airwing  assets. 

•  Two  squadrons  of  F- 14 A,  Air  Interceptors. 

•  Two  squadrons  of  F/A-18D,  Light  Attack  and  Fighters. 

•  One  Squadron  of  A-6E,  Medium  Attack  and  Tankers. 

•  One  squadron  of  EA-6B,  Electronic  Countermeasures. 

•  One  squadron  of  S-3B,  Anti-surface  and  Subsurface,  Tankers. 

•  One  squadron  of  E-2C,  Early  Warning. 

•  One  squadron  of  helicopters  H-3  or  SH-60F,  Anti-submarine  and  Logistics. 

The  helicopters  are  not  included  in  the  analysis  portion.  Helicopter  launches  and 
recoveries  do  not  have  a  significant  impact  on  the  airplan.  The  model  proposed  in 
Chapter  IV  accommodates  all  other  assets  common  to  the  aircraft  carrier  including 
Carrier  Onboard  Delivery  by  fixed  wing  assets.  The  analysis  is  directed  strictly  at 
organic  fixed  wing  assets. 

The  flight  qualification  of  squadron  pilots  is  an  important  factor  in  the  daily 
airplan  production.  Safety  requirements  imposed  by  the  Landing  Signal  Officer  Naval 
Air  Training  Operations  Program  Standardization  (LSO  NATOPS)  dictate  that  each 
squadron  pilot  fly  a  minimum  of  one  night  landing  within  a  seven  day  period  to  remain 
eligible  to  fly  at  night  from  the  aircraft  carrier.  If  this  minimum  is  not  met,  a  series  of 
flights  must  be  performed  to  requalify  a  squadron  pilot  to  become  eligible  to  land  at 
night.  Responsibility  for  pilot  night  currency  lies  with  squadron  Operations  Departments. 
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TABLE  1  NOTIONAL  AIRWING 


SQUADRON 

TYPE 

AIRCRAFT 

TYPE 

NUMBER 

OF 

AIRCRAFT 

NUMBER 

OF 

A/C  AVAIL 

NUMBER  OF 
SQN  PILOTS 

VF 

F-14A 

10  +/-  1 

6  +/- 

15 

VF 

F-14A 

10  -h/-  1 

6  +!- 

15 

VFA 

F/A-18D 

11  -»-/ 

7  +!- 

18 

VFA 

F/A-18D 

11  1 

7  +!- 

18 

VA 

A-6E 

10  ATTACK 

3  TANKER 

7  BOMBER 

2  TANKER 

14 

V.4lO 

EA-6B 

4 

3  +/- 

7 

VS 

S-3B 

7  1 

5  +/- 

15 

VAW 

E-2C 

4  or  5 

3  +!- 

10 

They  must  manage  night  sorties/landings  to  maximize  the  number  of  night  current  pilots. 
Maintaining  pilot  night  currency  also  places  constraints  on  the  carrier  planning  staff.  The 
ship  must,  as  a  minimum,  plan  for  120  night  sorties  per  seven  day  period. 

Squadron  maintenance  departments  must  perform  daily  maintenance  on 
aircraft  for  them  to  be  mission-capable  for  subsequent  flights.  Aircraft  turnaround  time 
is  a  major  limitation  on  the  size  of  the  daily  airplan. 

C.  CARRIER  AIRPLAN 

The  airplan  can  be  described  as  a  two  dimensional  array.  Each  element  of  the 
array  is  a  complex  entity  that  represents  what  a  squadron  is  tasked  to  accomplish  during 


a  specific  period  of  the  day.  The  periods,  as  defined  earlier,  are  airplan  cycles.  The 
entities  in  each  cell  of  the  array  are  events,  or  flights  of  sorties. 

Tasking  often  will  determine  the  cycle  time,  which  can  vary  throughout  the  day, 
but  is  usually  between  one  and  two  hours.  Cycle  length  has  a  direct  impact  on 
production  of  the  daily  airplan.  The  following  list  gives  the  potential  impact  a  change 
in  cycle  time  can  have. 

•  Change  necessary  fuel  loads  for  each  aircraft  type. 

•  Change  airborne  tanker  requirements. 

•  Type  and  number  of  aircraft  available  for  current  and  future  missions.  This  is  due 
to  turnaround  times. 

•  Combat  Packages. 

•  Search  area  coverage  and  on-station  time. 

•  PIM  due  to  time  into  the  wind  for  launch  and  recoveries. 

•  Amount  of  tactical  training  an  event  can  accomplish  due  to  fuel  constraints. 

One  major  problem  with  cycle  time  is  that  there  is  not  a  single  length  which  best  satisfies 
each  squadron’s  operations  and  training  requirements. 

A  callsign  is  assigned  to  each  squadron  event.  It  consists  of  a  number,  a  letter,  and 
another  number.  The  first  number  determines  launch  cycle.  The  letter  is  the  squadron 
identifier,  A-H  for  organic  airwing  assets  and  X  for  logistics  assets  not  actually  part  of 
the  airwing.  The  final  digit  specifies  events  within  each  squadron.  Figure  2  is  a  typical 
carrier  airplan.  Some  information  obtained  from  the  airplan  is  listed  below: 

•  Event  callsign. 
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Figur*  2  Carrier  Airplan 
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•  Number  of  aircraft  in  an  event. 


•  Launch  time. 

•  Recovery  time. 

•  Fuel  load  if  non-standard. 

•  Mission  areas. 

•  Tanking  requirements  for  each  sortie. 

•  Combat  Package/Ordnance  loadout. 

•  Notes  particular  to  each  flight. 

•  Alert  status. 

•  Emergency  information. 

D.  GOAL 

The  goal  of  this  thesis  is  to  address  the  first  two  areas  of  the  proposal  and  suggest 
a  number  of  models  for  possible  development  by  other  thesis  students  from  the  following 
departments, 

•  Operations  Research. 

•  Computer  Science. 

•  Information  Systems. 

A  prototype  of  one  of  the  suggested  models  is  included  for  evaluation. 

E.  APPROACH 

The  approach  taken  was  to  organize  a  number  of  airplans,  then  analyze  aspects  of 
the  airplans  to  determine  the  factors  that  limit  the  daily  production  of  the  airplan.  An 
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attempt  is  made  to  quantify  those  aspects  that  have  the  greatest  influence  on  the 
difference  between  a  feasible  and  unfeasible  aiiplan.  While  it  is  obvious  there  could  be 
numerous  sortie  mixtures  on  any  given  airplan,  the  goal  is  to  characterize  the  typical 
aiiplan  as  closely  as  possible. 

F.  LIMITATIONS 

As  stated  above,  there  are  numerous  possible  sortie  mixtures  for  any  given  set  of 
aiiplan  constraints.  That  number  expands  rapidly  when  all  possible  mission  types  are 
taken  into  consideration.  The  sheer  size  of  the  problem,  and  knowledge  of  the  process, 
forces  constraints  from  the  outset. 

These  constraints  are  complexity,  compatibility  and  cost  limitations.  First,  the 
model  should  be  easy  to  use  for  someone  with  basic  computer  knowledge.  The  model 
should  also  be  small  enough  to  run  in  a  reasonable  amount  of  time  on  a  relatively  small 
computer  (386SX  based  IBM  or  compatible  computer  with  one  or  two  megabytes  of 
random  access  memory).  This  is  the  class  of  computer  normally  available  in  the  Strike 
Operations  Office  of  an  aircraft  carrier.  Finally,  the  software  used  for  the  prototype 
model  should  be  multi-purpose,  off  the  shelf,  commercially  available  programs 
preferably  already  used  on  the  carrier.  If  the  end  user  has  to  purchase  software,  it  was 
decided  that  the  cost  should  be  kept  under  $500.00. 
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n.  DATABASE  ESTABLISHMENT 

A.  INTRODUCTION 

This  chapter  explores  the  structure  of  a  database  that  will  benefit  mission  planners 
in  STROPS.  The  carrier  airplan  is  a  dynamic  document  with  inputs  coming  from 
numerous  different  areas.  The  structure  of  the  database  designed  for  storage  of  airplans 
is  dependent  on  the  intended  use.  A  useable  database  structure  was  sought  with  two 
goals  in  mind,  analysis  of  the  airplan  and  airplan  production.  For  airplan  analysis,  the 
format  must  allow  quick  calculations,  sorting  across  numerous  Aelds  and  convenient 
storage  of  statistics.  For  airplan  production,  the  primary  consideration  was  table  look 
up,  or  query  ability.  The  production  phase  will  be  addressed  with  the  model 
recommendations. 

B.  DATABASE  TERMINOLOGY 

Before  addressing  the  actual  database  structure,  some  terminology  must  be 
explained.  A  database  can  be  thought  of  as  a  list  of  items  with  traits  describing  them. 
These  items  are  called  entities  and  the  traits  attributes.  In  other  words,  an  entity  is  some 
object  that  occurs  in  nature.  The  object  is  made  unique  by  assigning  its  attributes  certain 
values.  For  example,  assume  a  database  is  constructed  of  pilots  in  a  squadron.  The 
obvious  entity  would  be  the  PILOT.  The  PILOT  entity  would  have  attributes  such  as, 
first,  middle,  and  last  names,  department,  rank,  etc.  Each  of  these  attributes  is  given 
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values  in  the  database.  Another  way  of  picturing  entities  and  attributes  is  to  think  of 
entities  as  rows  of  a  table  and  attributes  as  columns.  Figure  3  is  a  schematic  of  the 
PILOT  entity.  [Ref  2] 

The  most  important  factor  in  the  construction  of  databases  is  the  key.  A  key  is  an 
attribute  or  group  of  attributes  that  make  an  entity  or  row  unique.  In  the  PILOT 
example,  a  key  is  the  Social  Security  number.  The  key  uniquely  determines  each  pilot 
in  the  squadron. 

The  power  of  well  structured  databases  is  the  ability  to  quickly  search  through  and 
find  information  about  specific  entities  or  groups  of  entities,  and  the  ability  to  sort  all 
files  depending  on  attribute  values.  These  processes  are  called  queries  and  sorts.  The 
ability  to  ask  the  database  to  produce  all  records  that  have  a  certain  value  for  a  specific 
attribute  or  to  sort  the  database  according  to  a  certain  attribute  value  provides  the  user 
quick  access  to  significant  amounts  of  information. 

C.  DATABASE  SCHEMA 

A  tabular,  or  flat  file,  database  structure  was  selected  for  use  in  this  project.  This 
was  done  with  the  end  user  in  mind.  The  simple  structure  accomplishes  the  analysis  and 
production  goals  listed  earlier  and  should  be  easily  understood  by  most  users.  The 
structure  allows  for  quick  sorting  and  queries  without  the  complexity  of  an  Object 
Oriented  or  Entity/Relationship  database  model.  It  also  loosely  follows  the  message 
format  used  for  promulgating  the  airplan  throughout  the  battlegroup  after  production. 
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PILOT 

FNAME  MINIT  LNAME  SSN  SEX  ADDRESS  DEPT  RANK  QUAL 

ATTRIBUTE  VALUES 

FNAME  -  CHARACTER  (10) 

MINIT  -  CHARACTER  (3) 

LNAME -CHARACTER  (15) 

SSN  -  NUMBER  OF  FORM  ##-###-#### 

SEX- CHARACTER  (1) 

ADDRESS  -  CHARACTER  (25) 

DEPTARTMENT  -  CHARACTER  (15) 

RANK  -  CHARACTER  (5) 

MISSION  QUAUFICATION  -  CHARACTER  (5) 

Flgura  3  Pilot  Entity 
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1.  The  EVENT  Entity 


Referring  to  the  airplan  description,  the  basic  element  of  the  airplan  is  the 
sortie.  Each  sortie  is  an  individual  aircraft  with  a  specific  mission.  The  entity  used  for 
the  basic  record  of  the  proposed  database  however,  is  the  EVENT.  Analysis  determined 
that  a  majority  of  sorties  launched  were  part  of  a  flight,  making  up  an  event.  The 
selection  of  the  EVENT  as  the  basic  entity  in  the  database  eliminated  many  duplicate 
values,  reduced  the  size  of  each  file  in  the  database,  and  eliminated  the  necessity  of  an 
additional  attribute.  The  selection  of  the  EVENT  entity  also  conforms  to  the  prototype 
model  description  in  Chapter  IV. 

The  EVENT  entity,  seen  in  Figure  4,  is  composed  of  number  of  attributes. 
The  values  for  each  attribute  are  also  listed  in  Figure  4.  Since  the  airplan  data  is  stored 
in  several  different  files,  the  uniqueness  of  each  EVENT  entity  is  important  only  in 
some  respects.  This  problem  is  addressed  in  the  discussion  of  the  file  types.  Suffice  to 
say,  if  individual  flights  are  studied,  where  uniqueness  is  required,  a  DATE  attribute 
can  be  added  to  achieve  uniqueness.  The  addition  of  a  DATE  field  is  a  simple  extension 
of  the  current  structure.  In  this  case,  the  key  for  these  entities  is  the  combination  of  the 
DATE  and  CALLSIGN  attributes. 

2.  AIRPLAN  Files 

The  base  file  or  storage  file  is  the  AIRPLAN  file.  Each  of  these  files 
contains  a  list  of  EVENT  entities  that  make  up  a  single  daily  airplan.  The  file  name 
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VALUES 

CALL1  -  INTEGER  1.2,3,... 

SON  -  LETTER  A-l  ORGANIC  X  NON-ORGANIC 
CALL2  -  INTEGER  1 ,  2, 3,  4 
QUANTITY  -  INTEGER  1 , 2, 3. . . . 

PRIMARY  MISSION  -  SEE  APPENDIX  A 
SECONDARY  MISSION  -  SEE  APPENDIX  A 
LAUNCH  CYCLE  -  INTEGER  1, 2. 3, . . . 
RECOVER  CYCLE  -  INTEGER  1, 2. 3, . . . 

DAY  OR  NIGHT  -  BINARY  0  -  DAY ,  1  -  NIGHT 


Figure  4  Event  Entity 
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corresponds  to  a  date  in  the  form  MMDDYY.  The  actual  date  is  not  important  but  the 
uniqueness  of  the  date  is.  The  date  is  the  key  element  for  finding  an  individual  airplan 
to  analyze  or  reproduce.  Within  the  AIRPLAN  files  the  key  attribute  for  the  EVENT 
entity  is  the  callsign. 

D.  DATA  OBTAINED 

The  data  consists  of  six  months  of  deployment  airplans.  The  deployment  was 
made  by  Carrier  Airwing  11  (CVW-11)  embarked  in  USS  Abraham  Lincoln  (CV-72)  to 
the  Pacific  and  Indian  Oceans  during  May  through  November  of  1991.  This  was 
considered  a  typical  Western  Pacific,  peace  time  deployment.  While  the  Persian  Gulf 
War  was  in  the  recent  past,  this  had  little  effect  on  how  business  was  conducted  during 
this  deployment. 

Approximately  1 10  airplans  were  obtained.  The  1 10  airplans  vice  the  1 80  days  that 
make  up  six  months,  is  explained  by  taking  into  account  inport  periods.  It  is  not 
uncommon  for  30  or  40  percent  of  a  peacetime  deployment  to  be  spent  in  foreign  ports. 

Some  of  the  1 10  airplans  were  eliminated,  most  because  they  were  no-fly  days  or 
minimum  fly  days.  These  airplans,  from  experience,  do  not  represent  normal  business 
aboard  the  carrier.  Furthermore,  production  of  these  airplans  does  not  pose  a  great 
problem  for  Strike  Operations.  After  this,  75  airplans  remained.  Most  structure  oriented 
information  was  taken  from  the  75  remaining  airplans.  Detailed  analysis  was  then 
conducted  on  34  airplans. 
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ni.  AIRPLAN  ANALYSIS 


A.  APPROACH 

The  airplan  can  be  viewed  as  columns,  rows  or  individual  blocks.  Each  of  these 
views  is  taken  in  the  analysis  of  the  individual  airplan  files.  Each  view  gives  insight  into 
a  different  facet  of  the  airplan  and  carrier  operations  in  general.  If  columns  are 
considered,  the  information  derived  from  a  number  of  airplans  refers  to  cycle 
comparisons  such  as  average  number  of  launches  per  cycle.  Squadron  launch  averages 
can  also  be  obtained  along  with  how  these  affect  the  airplan  throughout  the  day. 
Analysis  along  rows  yields  information  concerning  individual  squadron  operations  and 
how  they  compare.  Total  number  of  sorties  per  squadron,  and  the  day  and  night  sortie 
breakdown,  are  the  primary  pieces  of  information  obtained  from  horizontal  analysis  of 
the  airplan.  Individual  block  analysis  of  the  surplan  focuses  on  mission  areas,  squadron 
operating  procedures  and  sortie  duration.  This  enables  the  analyst  to  compare,  on  a 
sortie  by  sortie  basis,  how  different  squadrons  and/or  aircraft  types  differ  in  their 
operating  procedures.  Individual  sortie  analysis  also  allows  the  analyst  to  characterize 
each  airplan  with  an  emphasis  on  mission  area. 

The  goals  of  the  analyses  were  to  gain  insight  into  enough  facets  of  the  airplan  to 
make  recommendations  on  possible  ways  to  improve  the  production  process.  In  addition 
to  insight,  it  was  necessary  to  ensure  that  the  airplans  obtained  were  a  reasonable  sample 
of  the  overall  population.  The  fact  that  the  airplans  obtained  were  actually  approved  and 
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flown  may  make  the  second  goal  seem  trivial,  but  approval  alone  is  no  guarantee  that  an 
airplan  is  "good."  It  would  be  less  than  optimal  to  start  out  with  a  group  of  substandard 
airplans. 

B.  ORGANIZATION 

The  airplans  were  obtained  in  standard  hard  copy  airplan  format.  After  the 
structure  was  established,  approximately  one  hour  was  needed  to  transfer  a  hard  copy 
airplan  to  a  computer  format  that  could  be  used  for  analysis.  The  transformation  to  a 
working  data  set  was  accomplished  in  Paradox  3.5,  the  software  choice  for  the  database 
portion  of  this  thesis  and  model  development. 

Initially,  the  data  analysis  was  structure  oriented.  Total  cycles,  total  sorties  and 
day  night  ratios  from  the  75  airplans  were  examinefi  in  an  attempt  to  limit  unnecessary 
data  entry.  From  this  initial  examination  of  the  airplans,  a  cursory  definition  of  a 
standard  airplan  was  made.  Table  2  shows  the  results.  It  was  determined  that  further 
analysis  and  subsequent  model  development  should  be  structured  around  the  standard 
(average)  airplan.  Table  2  shows  the  standard  airplan  to  have  four  day  cycles,  three 
night  cycles  and  approximately  85  sorties  flown  throughout  the  day. 

A  group  of  34  airplans  was  organized  into  individual  airplan  files.  The  files  are 
constructed  of  the  EVENT  entities  that  make  up  a  daily  airplan.  From  this  format,  the 
files  were  merged  and  sorted  for  the  analysis  of  each  area.  The  merging  of  the  daily 
airplans  took  place  in  Quattro  Pro  3.0.  Quattro  Pro  was  chosen  for  its  built-in  ability 
to  communicate  with  Paradox  3.5,  and  for  its  ability  to  perform  complex  logical 
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TABLE  2  CYCLE  AND  SORTIE  INFORMATION 


DAY 

CYC 

DAY 

SORT 

SORT/ 

DCYC 

MITE 

CYC 

NITE 

SORT 

NSORT/ 

NCYC 

TOT 

CYC 

TOT 

SORT 

AVG 

4.33 

44.24 

14.75 

2.9 

40.13 

13.87 

7.23 

84.36 

STD 

DEV 

1.06 

15.01 

5.00 

0.80 

12.14 

2.04 

1.07 

16.13 

MAX 

7 

84 

26.33 

5 

69 

19.67 

10 

140 

MIN 

1 

16 

6 

1 

11 

8 

4 

59 

selections  and  basic  statistical  calculations.  Using  the  spreadsheet  environment  made 
parsing  the  data  easier. 

1.  DAILY  Files 

As  stated  above,  a  file  was  made  with  the  contents  of  each  individual  daily 
aixplan.  These  files  are  used  in  the  production  application.  The  information  is  needed 
from  each  airplan  to  form  the  other  analysis  files.  Data  such  as  number  of  day  and  night 
cycles,  total  sorties,  and  overall  mission  percentages  are  used  by  the  production 
application  to  characterize  an  airplan  for  future  use.  This  information  is  presented  in 
Table  3.  Table  4  is  a  portion  of  a  DAILY  file. 

2.  OVERALL  File 

A  file  of  all  recorded  events  was  made  by  combining  the  DAILY  files.  This 
OVERALL  file  contains  all  events  in  the  database.  The  size  of  the  file  precluded  its  use 
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TABLE  3  DATABASE  SEARCH 
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TABLE  4  DAILY  FILE 
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for  all  but  the  simplest  calculations.  This  file  was  used  to  obtain  overall  airwing 
statistics.  The  size  of  the  Hie  and  nature  of  the  final  use  allowed  structuring  the 
OVERALL  file  without  a  DATE  field.  If  the  records  of  the  OVERALL  file  were 
required  to  be  unique,  a  "DATE"  field  could  easily  be  added.  During  analysis  of  the 
OVERALL  file  the  decision  was  made  to  eliminate  sorties  that  did  not  both  launch  and 
recover  on  the  carrier.  As  discussed  earlier  these  type  flights,  due  to  their  small  number, 
along  with  the  helicopter  sorties,  do  not  have  a  proportionally  large  impact  on  daily  flight 
operations. 

3.  SQUADRON  FUes 

A  file  was  also  formed  for  each  squadron.  These  Hies  are  made  up  of  all 
events  flown  by  each  squadron.  The  files  were  obtained  by  sorting  the  OVERALL  file 
on  the  squadron  letter  attribute.  These  files  have  little  use  to  the  scheduler  on  a  dtuly 
basis,  but  they  allow  collection  of  individual  squadron  statistics  over  an  extended  period. 

This  information  is  useful  for  comparison  within  the  airwing  and  for  comparison  with 
published  Navy  training  requirements.  The  comparison  with  Navy  training  and  readiness 
requirements  helps  ensure  that  each  squadron  is  provided  the  opportunity  to  maintain  full 
mission  capable  aircrew. 

Analysis  of  the  squadron  files  allowed  a  close  look  at  mission  areas  flown  by 
each  squadron.  In  the  case  of  the  F-14  and  F/A-18  squadrons,  comparisons  between 
sister  squadrons  were  made.  This  mission  data  was  important  when  designing  the 
interface  with  the  database  of  previously  flown  airplans,  because  the  published 
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requirements  for  mission  readiness  in  each  mission  area  can  be  used  as  scheduling 
guidelines. 

C.  TECHNIQUES  USED 

In  each  of  the  files,  it  was  necessary  to  use  logical  comparisons  to  gather 
information  from  the  data.  The  logical  functions  of  Quattro  Pro  proved  invaluable  in  this 
process.  The  statistical  functions  of  the  Quattro  Pro  spreadsheet  package  also  proved 
useful.  Appendix  B  contains  the  functions  and  macros  used  in  the  analysis.  Numerous 
samplings  were  taken  from  the  data.  The  analysis  was  approached  by  extracting  as  much 
information  as  possible  from  each  file  according  to  the  file  type.  The  results  are 
discussed  in  a  similar  fashion. 

1.  DAILY  flies 

Statistics  were  collected  on  the  DAILY  files  with  the  goal  of  characterizing 
a  typical  daily  aiiplan.  This  characterization  was  needed  for  two  reasons.  The  first 
reason  is  for  comparison  with  the  combined  data,  or  the  OVERALL  file.  The  second 
use  is  in  distinguishing  airplans  in  a  way  that  would  be  helpful  during  airplan  production. 
This  characterization  is  accomplished  using  the  parameters  with  which  the  ASTKE 
structures  each  day’s  aiiplan.  These  parameters  are: 

•  Number  of  day  cycles 

•  Number  of  night  cycles, 

•  Number  of  total  sorties. 

•  Time  flight  operations  will  commence. 
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The  time  will  not  be  part  of  the  analysis  but  it  is  accommodated  by  the  prototype  model. 
The  reason  for  this  is  the  that  the  hour  when  flight  operations  commence  or  terminate 
is  not  as  important  as  the  number  of  day  and  night  cycles.  In  addition  to  the  above  listed 
parameters,  three  others  were  examined,  night  sorties,  squadron  totals  and  mission 
influences.  Night  sortie  importance  to  maintain  pilot  night  currency  was  discussed 
earlier.  Mission  influences  further  differentiate  one  airplan  from  another.  Squadron  total 
sortie  information  for  comparison  with  training  requirements. 

It  was  thought  that  the  distribution  of  sorties  among  squadrons  would  be  a 
good  descriptor  of  the  airplan.  After  initial  analysis,  however,  it  was  discovered  it  is 
not.  This  measure  proved  fairly  constant.  Table  5  shows  these  results.  These  results 
also  match,  with  reasonable  tolerance,  the  expected  distribution  from  Reference  3.  The 
close  match  between  the  equitable  distribution  and  the  actual  distribution  tends  to  validate 
the  acceptability  of  the  airplans  used. 

The  numbers  and  types  of  cycles  and  sorties  are  additional  input  data.  The 
analysis  consisted  of  gathering  the  totals  from  the  daily  airplans  and  calculating  the 
necessary  statistics.  The  mission  data,  however,  was  not  straight-forward.  The  mission 
data  was  extracted  via  logical  comparisons  in  all  stages  of  the  analysis.  At  this  stage, 
the  mission  data  was  extracted  to  help  describe  a  certain  airplan.  The  logical  comparisons 
used  to  extract  mission  data  can  be  found  in  Appendix  B.  This  information  is  helpful 
in  picking  an  airplan  from  the  database  for  production. 


TABLE  5  AIRWING  SORTIE  DISTRIBUTION 


DAY 

AVG 


DAY 

STD 

DEV 


DAY 

MAX 


DAY 

MIN 


NIGHT 

AVG 


NIGHT 

STD 

DEV 


NIGHT 

MAX 


NIGHT 

MIN 


TOTAL 

AVG 


TOTAL 

STD 

DEV 


TOTAL 

MAX 


TOTAL 

MIN 


COUNT 


VF-1 

VF-2 

VFA-1 

VFA-2 

VA 

5.91 

5.71 

6.71 

6.59 

7.74 

2.77 

2.67 

2.93 

2.95 

3.18 

13 

13 

12 

13 

14 

2 

0 

2 

2 

2 

5.74 

5.59 

6.38 

6.56 

7.91 

2.05 

2.12 

2.44 

2.29 

2.90 

9 

9 

10 

10 

12 

0 

0 

0 

0 

0 

11.6 

11.29 

13.09 

13.15 

15.65 

2.36 

3.38 

2.99 

2.92 

3.17 

19 

20 

22 

22 

24 

8 

0 

8 

? 

12 

34 

34 

34 

34 

34 
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2.  OVERALL  File 


Once  all  the  daily  files  were  combined,  the  total  number  of  events  was  2176. 
The  total  number  of  sorties  flown  from  these  events  was  3258.  This  yields  an  average 
of  1.49  sorties  per  event.  The  standard  deviation  on  this  average  was  0.58  sorties.This 
information  shows  that  the  airwing,  overall,  launches  with  either  one  or  two  aircraft 
most  of  the  time.  This  fact  helped  determine  the  use  of  the  EVENT  entity  as  the  basic 
entity  of  the  database  for  the  analysis  and  prototype  production  model. 

An  interesting  piece  of  information  from  the  overall  file  was  the  day  to  night 
sortie  ratio.  Of  the  3258  sorties  entered  into  the  database,  1619  recovered  at  night.  This 
high  percentage  of  night  sorties,  49.7  percent,  shows  the  attempt  being  made  to  maintain 
pilot  night  currency  and  the  ability  of  the  airwing  to  operate  at  night.  "Was  the  high 
percentage  of  night  sorties  planned  or  did  tasking  work  out  to  provide  sufficient  day  to 
night  ratio?"  A  discussion  with  the  Assistant  Strike  Operations  Officer  on  the  Abraham 
Lincoln  answered  this  question.  The  policy  used  during  this  period  of  operations  was 
to  schedule  the  airplan  as  tasked  without  regard  for  night  landings.  If  airwing  pilot  night 
currency  began  to  suffer,  only  then  was  emphasis  placed  on  maximizing  the  number  of 
night  sorties  within  the  constraints  applied  by  AIROPS.  Some  of  the  costs  associated 
with  flying  too  many  night  sorties  are  often  overlooked.  Night  flight  operations  are  not 
only  significantly  more  dangerous  than  day  operations  they  also  are  less  productive. 
Time  is  wasted  in  the  holding  pattern  or  Marshall  stack.  This  flight  time  could  be  use 
more  efficiently.  Time  spent  in  the  Marshall  stack  by  night  sorties  could  have  been  used 
for  secondary  mission  area  completion.  When  the  airplan  can  be  analyzed,  along  with 
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other  related  statistics  such  as  percent  pilots  night  current,  this  area  will  be  more  useful. 
The  data  needed  for  this  analysis  is  not  available  now. 

The  OVERALL  file  produced  the  airwing’s  average  sorties  per  event,  average 
number  of  cycles  flown  per  event  and  the  associated  deviations  for  each.  These  allow 
the  analyst  to  estimate  the  number  of  flight  hours  flown  by  the  airwing  for  each  aiiplan 
in  the  database.  This  also  allows  an  estimate  of  the  number  of  events  that  normally 
launch  in  any  cycle.  Given  the  constraints  placed  on  the  airplan  by  Air  Operations  of 
approximately  15  sorties  per  night  recovery,  one  can  estimate  the  number  of  events 
allowed  to  launch  during  any  given  cycle. 

The  final  area  of  interest  in  the  OVERALL  file  was  the  mission  data.  This 
information  was  extracted  from  the  file  through  a  series  of  logical  comparisons.  The 
mission  portion  of  the  airplan  can  be  broken  down  into  three  areas,  primary,  secondary 
and  tertiary.  Every  event  has  a  primary  mission.  While  every  aircraft  is  capable  of 
accomplishing  multiple  missions  on  a  single  sortie,  the  assignment  of  secondary  and 
tertiary  missions  depends  several  factors.  Analysis  showed  the  number  of  secondary  and 
tertiary  missions  was  relatively  small  compared  to  the  number  of  aircraft  that  are  multi¬ 
mission.  Only  863  of  3258  sorties  or  26.5  percent  had  official  secondary  missions  and 
63  or  2.6  percent  had  tertiary  missions.  The  decision  was  made  to  discard  tertiary 
missions  as  a  critical  factor  in  the  analysis  and  production  phase  of  the  airplan.  The 
model  has  capability  to  accommodate  tertiary  missions,  but  the  analysis  will  not  include 
them. 
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Table  6  shows  the  overall  mission  breakdown  for  the  airwing.  Appendix  A 
contains  short  a  explanation  of  each  mission  area.  The  primary  and  secondary  missions 
were  given  the  same  weight  in  the  analysis;  no  added  weight  is  given  to  either  mission 
based  on  its  relative  position  on  the  airplan.  This  is  strictly  a  count  of  actual  times  a 
mission  occurred  on  the  airplan. 

A  byproduct  of  the  mission  data  analysis  is  the  number  of  mission  areas 
needed  to  cover  the  airwing’s  tasking  and  training.  Twenty-three  mission  areas  account 
for  approximately  94  percent  of  airwing  flights.  These  numbers  will  be  compared  with 
squadron  mission  statistics  in  the  next  section. 

3.  SQUADRON  Files 

The  SQUADRON  files  gave  valuable  insight  into  sortie  and  mission 
distributions.  These  files  lend  credence  to  each  spiecific  airplan’s  validity.  As  seen  in 
Table  5,  the  comparison  between  sister  squadrons  was  within  one  half  of  a  percent  in 
both  cases.  The  distribution  of  sorties  throughout  the  airwing  comes  close  to  the  mix 
required  to  maintain  aircrew  qualifications.  Table  7  shows  total  sortie  numbers  by 
squadron.  Again,  the  comparison  made  between  sister  squadrons  tends  to  validate  the 
airplans  used. 

SQUADRON  files  provided  another  chance  to  analyze  mission  data.  A 
similar  technique  to  gathering  mission  data  was  applied  to  each  of  the  SQUADRON  files. 
Table  8  shows  the  distribution  of  each  mission  area  over  the  airwing. 
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TABLE  7  SQUADRON  SORTIE  STATISTICS 


SQDN 

TOTAL 

SORTIES 

NIGHT 

SORTIES 

AVG  » 
CYCS 

PER 

SORTIE 

STD 

DEV 

AVG 

A/C 

PER 

EVENT 

STD 

DEV 

VF 

445 

217 

1.13 

0.489 

1.87 

0.463 

VF 

443 

212 

1.13 

0.464 

1.83 

0.430 

VFA 

497 

246 

1.05 

0.351 

1.95 

0.566 

VFA 

502 

246 

1.04 

0.389 

1.89 

0.597 

VA 

598 

299 

1.03 

0.176 

1.34 

0.497 

VAQ 

255 

124 

1.09 

0.311 

1.085 

0.279 

VS 

339 

187 

1.44 

0.527 

1.063 

0.243 

VAW 

178 

88 

1.754 

0.634 

1.01 

0.130 

While  some  of  the  mission  areas  are  aircraft  specific,  such  as  anti-air  warfare  missions 
like  AIC,  ACM  and  CAP,  the  information  in  Table  8  shows  how  the  shared  missions 
are  divided  among  those  capable  of  doing  them.  The  percentages  in  Table  8  are,  again, 
totals  of  sorties  that  had  a  given  mission  assigned  with  no  weight  given  to  whether  the 
mission  was  assigned  as  a  primary  or  secondary  mission.  This  explains  why  neither  the 
columns  nor  rows  sum  to  100.  The  numbers  should  only  be  used  for  comparison  within 
the  airwing.  The  OTH  column  accounts  for  unique  mission  assignments,  a  conglomerate 
of  rarely  flown  missions. 
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Some  interesting  information  is  available  in  Table  8.  Mainly,  the  distribution 
of  certain  primary  mission  areas  within  the  airwing.  The  distribution  of  tanking  sorties 
is  an  interesting  example.  There  are  only  two  aircraft  that  can  provide  organic  airborne 
tanking  to  the  rest  of  the  airwing,  the  A-6E  and  S-3A.  Approximately  37  percent  of 
A-6E  sorties  were  tasked  with  either  the  mission  tank  (MTNK)  or  recovery  tank  (TNK) 
mission  compared  to  over  65  percent  of  S-3A  sorties.  When  more  data  is  available 
through  saving  airplans  in  an  easily  analyzed  format,  the  ship  and  airwing  will  have  a 
way  to  compare  shared  missions  to  ensure  an  equitable  distribution. 

The  information  that  proved  valuable  for  the  model  choice  from  both  Tables 
5  and  7  was  the  large  number  of  possible  mission  combinations.  Narrowing  the  number 
of  mission  areas  to  23  left  an  average  of  only  seven  percent  of  each  squadron’s  total 
sorties  unaccounted  for.  This  led  to  the  conclusion  that  mission  data  is  much  too  fluid 
to  account  for  fully  in  a  prototype  model. 

Some  of  the  information  from  Table  8  may  be  confusing  to  the  reader 
unfamiliar  with  carrier  and  airwing  operations.  One  such  area  is  the  high  percentage  of 
E-2C  (VAW)  sorties  scheduled  for  Touch  and  Goes  (TG/T).  This  is  common  among 
most  airwings.  The  E-2C  is  a  dual  piloted  aircraft.  To  maintain  night  currency,  it  is 
common  for  one  pilot  to  fly  a  touch  and  go  and  the  other  pilot  fly  the  final  landing. 
When  night  sorties  are  scarce,  this  technique  is  used  by  the  airwing  to  boost  VAW  pilot 
night  currency.  Another  point  brought  out  by  Table  8  is  seen  in  the  Tactical  Air 
Reconnaissance  Pod  (TARPS)  mission  column.  It  is  common  for  only  one  VF  (F-14A) 
squadron  to  fly  all  TARPS  missions.  This  is  due  to  the  aircrew  training  required  for  the 
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TARPS  mission  and  the  cost  of  the  TARPS  pods.  The  extra  TARPS  sorties  flown  by 
VF-2  were  partially  compensated  for  in  the  AIC  mission  area.  VF-1  flew  approximately 
10  percent  more  AIC  missions  than  VF-2. 

D.  RESULTS  SUMMARY 

The  airplans  obtained  proved  to  be  good  candidates  for  future  use.  The  distribution 
of  sorties  and  missions  follows  the  necessary  requirements  for  readiness  as  prescribed  in 
the  joint  AIRPAC/AIRLANT  Training  and  Readiness  Instruction.  The  analysis  of  the 
breakdown  of  day  and  night  sorties  throughout  the  airwing  showed  these  airplans  provide 
an  equitable  mixture  and  a  chance  for  each  squadron  to  maintain  a  maximum  number  of 
night  current  pilots,  without  flying  an  unnecessarily  high  number  of  total  sorties  at  night. 
The  airplans  analyzed  had  approximately  50  percent  of  the  sorties  flown  recovering  at 
night.  While  this  might  seem  a  little  higher  than  required,  it  is  not  unreasonable.  The 
sortie  per  cycle  rate  was  found  to  be  IS  during  the  day  and  14  at  night  which  confirms 
known  limitations  applied  by  AIROPS.  Deviations  in  number  of  cycles,  sorties  and 
sorties  per  cycle  were  found  to  be  small. 

Mission  data  showed  a  relatively  small  percentage  of  sorties  being  launched  with 
secondary  and  tertiary  missions,  25  percent  and  3  percent  respectively.  Mission  analysis 
also  confirmed  standard  operations  in  numerous  areas  such  as;  TARPS,  Touch  and 
Goes,  and  Airborne  Tanking.  Approximately  95  percent  of  sorties  flown  from  the 
carrier  can  be  accounted  for  using  23  missions.  This  number  is  reduced  when 
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considering  only  a  single  aircraft  type  but  the  number  of  mission  combinations  is  still 
quite  large.  This  fact  will  affect  the  feasibility  of  different  prototype  models. 
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rv.  MODEL  RECOMMENDATIONS 


A.  POSSIBLE  SOLUTIONS 

Several  common  operations  research  techniques,  each  with  its  strengths  and 
weaknesses,  exist  for  solving  scheduling  oriented  problems.  One  of  the  most  useful 
techniques  is  mathematical  programming.  Two  possible  mathematical  programming 
approaches  will  be  discussed. 

1.  Expected- Value  Coefficient  Linear  Program 

A  linear/integer  program  could  be  used  to  solve  the  problem  of  the  airplan 
production.  In  this  case,  the  averages  for  total  sortie  and  mission  area  breakdowns 
gathered  in  Chapter  ni  would  be  used  as  constraint  coefficients  for  a  linear  program. 
The  division  of  total  sorties  and  day/night  mixture  within  each  squadron  could  be  treated 
as  constant  over  a  long  period  of  time  (a  dqiloyment,  for  example).  This  method  would, 
given  proper  formulation,  provide  an  optimal  mixture  of  sorties  over  an  average  number 
of  cycles.  The  basic  template  could  then  be  modified  by  Strike  Operations  to  meet  the 
actual  tasking  for  the  next  day. 

2.  Interactive  Linear  Program 

The  analysis  from  the  Chapter  III  also  suggests  an  interactive  linear  program 
or  optimization  model.  Unlike  the  expected  value  model,  this  would  take,  as  input,  the 
known  data  for  the  next  day’s  airplan.  That  information  could  include: 
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•  Number  of  day  cycles. 

•  Total  number  of  sorties  allowed. 

•  Number  of  up  (fiyable)  aircraft  for  each  squadron. 

•  Mission  priorities. 

•  Division  of  sorties  within  the  airwing. 

•  A  small  amount  of  historical  data. 

An  interactive  program  could  then  formulate  a  unique  linear  program  each  day.  A  model 
of  this  type  would  be  very  dynamic.  An  airplan  could  be  formulated  almost  to 
completion. 

3.  Discussion  of  Mathematical  Programming  Approaches 

These  two  approaches  were  seriously  considered  for  the  prototype  model. 
A  major  portion  of  the  analysis  was  directed  towards  designing  an  adaptation  of  the 
linear  program  found  in  Reference  4  which  could  be  adapted  to  either  approach.  The 
interactive  linear  program  was  chosen  initially.  It  was  quickly  determined  that  the 
amount  of  interaction  adversely  impacted  the  size  and  complexity  of  the  problem.  The 
linear  program  quickly  grew  very  large.  Initially,  this  did  not  seem  to  warrant 
discarding  the  idea.  Eventually,  however,  as  the  results  approached  realistic  conditions, 
the  problem  formulation  grew  to  a  size  that  was  unmanageable  for  the  expected 
computing  power  of  the  intended  user.  Thus,  the  rejection  of  the  interactive  linear 
program  solution. 
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The  interactive  linear  program  problem  violates  two  of  the  requirements 
discussed  in  Chapter  I.  The  amount  of  interaction  required,  found  to  be  considerable  to 
make  the  linear  program  realistic,  violates  the  simplicity  requirement,  making  it  difficult 
for  the  program  to  be  introduced  and  used  in  the  fleet.  The  sheer  size  of  the  problem 
violated  the  cost  constraint.  The  optimization  package  in  Quattro  Pro  was  unable  to 
handle  either  of  the  above  discussed  linear  programs.  A  commercial  add-on  program  that 
works  within  Quattro  Pro  was  investigated  but  the  version  required  to  handle  even  a 
moderate-sized  airplan  cost  $1000  per  copy. 

The  expected  value  model  would  provide  only  one  airplan  template  for  use 
by  Strike  Operations  unless  there  existed  several  different  linear  programs  to  handle  a 
limited  mixture  of  total  sorties  and  number  of  cycles  allowed.  This  would  require  a 
different  formulation  for  each  template.  The  large  number  of  possible  missions  and 
mission  combinations  preclude  this  approach.  As  discussed  in  Chapter  III,  94  percent 
of  the  missions  are  accounted  for  with  23  mission  areas.  The  possible  combinations 
quickly  increase  the  size  and  complexity  of  a  linear  program. 

While  neither  of  the  optimization  programs  solved  the  problem,  they  were 
helpful  in  gaining  insight  into  the  carrier  airplan.  The  interactive  linear  program  in 
particular  could  be  a  valuable  tool  for  in-depth  airplan  analysis. 

4.  Iteration  Method 

A  computer  program  could  be  written  to  generate  all  possible  airplans  for  a 
given  number  of  cycles  and  sorties.  This  brute  force  approach  would  produce  a  very 
large  number  of  possible  airplans.  The  initial  number  of  airplans  could  be  reduced  by 
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placing  some  reasonable  constraints  on  the  generation  program.  The  output  from  the 
initial  program  could  then  be  run  through  a  number  of  culling  sub-programs  which  would 
sort  through  and  pare  down  the  list  until  a  reasonable  number  of  candidate  aiiplans 
remained.  This  method  is  an  excellent  project  for  a  Computer  Science  thesis  but  is 
rejected  here  for  size  and  complexity  reasons. 

B.  INTERACTIVE  DATABASE  SEARCH  MODEL 

A  approach  found  to  best  meet  the  simplicity  and  cost  requirements,  while 
achieving  the  established  goal,  to  assist  ASTKE  by  reducing  the  repetitive  work  he  must 
currently  accomplish,  proved  to  be  an  interactive  database  search  model.  The  basic 
procedure  for  this  model  is: 

•  Characterize  the  airplan  in  a  concise  way  that  benefits  the  production  process. 

•  Place  the  characterizations  into  a  database  that  can  be  searched  and  sorted  quickly 
and  easily. 

•  Provide  ability  to  retrieve  a  sample  of  a  few  airplans  from  what  would  be  a  larger 
more  cumbersome  database. 

•  Provide  a  means  to  make  minor  changes  to  the  chosen  airplan  template  and  save 
it  for  future  incorporation  into  the  database. 

1.  Assumption 

As  discussed  in  Chapter  II,  several  previously  flown  airplans  were  entered 
into  the  database  supported  by  both  Paradox  3.5  and  Quattro  Pro  3.0.  Constraints,  such 
as  number  of  sorties  per  cycle,  amount  of  airborne  fuel  available,  and  the  concern  over 
equitable  division  of  available  sorties,  are  assumed  to  be  at  least  partially  accounted  for 
if  the  proposed  airplan  for  the  next  day  is  based  on  an  airplan  that  has  already  undergone 
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the  scrutiny  necessary  for  approval.  The  analysis  backed  this  assumption.  The  airplans 
used  for  the  initial  database  were  composed  using  an  equitable  spread  of  sorties. 

2.  Model  Basics 

A  basic  description  of  the  chosen  model  follows.  A  more  user-oriented 
version  can  be  found  in  Appendix  C.  The  idea  behind  the  database  search  model  is  that 
Strike  Operations  be  given  an  initial  database  which  includes  several  "standard"  fly  days 
for  an  aircraft  carrier.  Through  the  process  of  updating  of  the  database  and  the  search 
file,  the  database  is  eventually  tailored  to  the  way  the  individual  ship  and  airwing  do 
business.  After  a  few  months  of  flying  the  original 'database  could  be  purged,  leaving 
only  that  ship’s  airplans  present. 

The  general  flow  through  the  model  is  accomplished  first  in  Paradox  where 
the  user  selects  a  candidate  airplan  via  menu  driven  queries.  The  date  associated  with 
that  candidate  airplan  is  the  file  name  for  that  aiiplan  in  Quattro  Pro.  The  spreadsheet 
file  or  files  are  then  viewed  in  Quattro  Pro.  Once  the  best  airplan  is  chosen  it  can  be 
altered  to  meet  specific  tasking.  Each  stage  of  the  application  will  be  discussed. 

3.  Paradox  3.5 

The  Paradox  portion  of  the  application  is  menu  driven  queries  that  prompt 
the  user  to  select  an  aiiplan  based  on  a  number  of  different  criteria.  Figure  6  is  a 
diagram  of  the  menus.  The  menus  were  constructed  using  Paradox’s  Personal 
Programmer  Feature,  which  allows  database  queries  to  be  saved  as  menus.  The  queries 
defined  by  the  interactive  menu  selection  and  user  inputs  ensure  selection  of  the  airplan 
which  best  meet  the  tasking  for  the  next  day. 


Figure  5  Paradox  Menu  Structure 
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The  choices  for  airplan  selection  are  made  by  querying  the  inputs  commonly  made  at  the 
beginning  of  airplan  construction.  The  six  query  choices  are: 

•  Number  of  day  cycles  and  night  cycles. 

•  Number  of  total  cycles. 

•  Number  of  total  sorties. 

•  Number  of  night  sorties. 

•  Number  of  total  cycles  and  total  sorties. 

•  Day  cycles,  night  cycles  and  total  sorties. 

Each  of  the  queries  above  returns  a  table  of  airplans  that  meet  the  desired  inputs. 
Additional  information  characterizing  the  airplans  is  available  in  the  resulting  query 
answer  table.  Along  with  the  date  corresponding  to  the  airplans  are  a  number  of  mission 
area  percentages.  These  percentages  reflect  the  number  of  sorties  on  that  airplan  that 
have  that  mission  as  a  primary  qt  secondary  mission.  This  further  distinction  gives  the 
scheduler  another  method  of  narrowing  the  possibilities. 

If  queries  are  unsuccessful  or  it  is  determined  by  ASTKE  that  flight 
operations  for  the  next  day  will  be  very  specific,  a  number  of  blank  templates  are 
available  for  constructing  an  airplan  from  scratch.  These  will  be  discussed  in  the  next 
section.  The  result  from  Paradox  is  simply  a  date  or  number  of  dates  corresponding  to 
Quattro  Pro  file  names.  The  user  uses  these  dates  to  choose  a  template  for  the  next  day’s 
airplan. 
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4.  Quattro  Pro 

The  portion  of  the  application  designed  in  Quattro  Pro  consists  of  two  file 
types  modifiable  to  meet  the  needs  of  the  ASTKE.  Both  are  airplan  templates,  one  is  a 
previously  flown  airplan,  the  other  is  a  blank  airplan  template.  The  end  result  is  the 
same,  an  airplan  that  can  be  published  directly  from  the  computer. 

A  series  of  macros  and  spreadsheet  functions  help  ASTKE  with  the  more 
tedious  tasks.  The  macros  and  functions  can  be  seen  in  Appendix  B.  They  accomplish 
line  drawing  and  computation  of  sortie  totals  for  each  squadron  and  each  cycle.  This  is 
accomplished  by  using  the  ability  to  name  and  hide  blocks  in  the  spreadsheet.  Where 
quantities  are  involved,  named  blocks  and  Quattro  Pro  functions  are  used  to  calculate  the 
appropriate  values.  Figure  6  depicts  the  layout  of  named  blocks  and  hidden  columns 
used  in  calculations.  The  blocks  are  summed  vertically  and  horizontally  to  receive  cycle 
launch  and  recover  totals,  squadron  day  and  night  sortie  totals,  and,  overall  total  day  and 
night  sortie  totals.  Presently  this  is  done  by  hand  and  must  be  done  each  time  a  change 
is  made  to  the  airplan.  Since  the  total  number  of  sorties  is  usually  an  externally  imposed 
constraint,  an  updated  total  relieves  ASTKE  of  the  need  to  consistently  recalculate  sortie 
and  cycle  totals. 

C.  CONCLUSIONS 

While  the  interactive  database  model  meets  the  goals  and  requirements  outlined  in 
Chapter  I,  it  has  some  limitations  namely  limits  of  the  macro  language  and  difficulty  in 
data  extraction.  They  are  lessened  with  spreadsheet  experience,  but  not  easily. 
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The  goal  is  to  provide  a  model  to  ASTKE  for  evaluation.  It  is  accomplished.  The 
prototype  model  can  be  experimented  with  at  little  cost  to  the  user.  If  the  concept  is 
accepted,  a  final  model  can  be  constructed  using  lessons  learned  from  the  prototype. 
Once  the  prototype  is  in  use,  an  extensive  database  of  airplans  will  be  available  for 
further  analysis. 
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V.  CONCLUDING  REMARKS 


A.  MODEL  USE 

The  interactive  database  model  described  in  Chapter  IV  will  be  provided  to  the 
Assistant  Strike  Operations  Officer  of  the  USS  Abraham  Lincoln  for  use  during  an 
upcoming  work-up  and  deployment  cycle.  The  results  will  determine  whether  further 
development  of  this  approach  is  warranted,  or  if  prototype  development  of  one  of  the 
other  models  discussed  should  be  investigated. 

Undoubtedly,  the  model  will  relieve  the  Assistant  Strike  Operations  Officer  of  some 
repetitive  tasks.  This  alone  does  not  warrant  development  of  a  final  model.  There  could 
be  other  problems  introduced.  After  the  trial  period,  the  Strike  Operations  team  should 
be  able  to  provide  valuable  inputs  to  a  final  model. 

B.  PROTOTYPE  REFINEMENTS 

One  refinement  to  be  accomplished  during  fleet  introduction  will  be  a  Quattro  Pro 
macro  to  assist  ASTKE  in  drafting  the  Air  Tasking  Order  (ATO)  that  is  promulgated  to 
the  warfare  commanders.  This  macro  will  also  enable  ASTKE  to  form  the  DAILY  files 
necessary  to  update  the  database  search  file.  This  macro  is  a  mirror  image  of  the  macro 
used  to  build  the  airplan  templates.  This  will  not  be  done,  however,  until  the  model  is 
more  thoroughly  tested. 
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C.  FURTHER  RESEARCH  PROJECTS 

If  it  is  determined  that  the  database  approach  satisfies  the  needs  of  Strike 
Operations,  the  final  model  should  be  a  stand-alone  program  designed  specifically  for  the 
task  of  writing  the  airplan.  The  prototype  model  described  in  Chapter  IV  is  limited  by 
the  software  chosen.  The  spreadsheet  environment  is  adequate  for  testing  the  idea  but 
a  program  written  with  the  single  goal  of  aiiplan  production  would  be  much  better.  A 
student  in  the  Computer  Science  Department  should  be  sought  to  accomplish  this  for 
thesis  work. 

In  addition  to  a  stand-alone  airplan  production  program,  another  thesis  project  is 
possible.  A  more  intricate  database  structure  could  be  developed  to  work  along  with  the 
final  model,  extracting  significant  data.  Once  again,  the  choice  of  software  present  limits 
the  data  collection.  Data  is  not  easily  extracted.  A  substantial  amount  of  spreadsheet 
knowledge  is  needed  to  extract  the  data  from  the  airplan  files.  Macros  can  be  written  to 
accomplish  the  data  extraction  but  the  macro  language  of  Quattro  Pro  is  not  as  flexible 
as  a  structured  programming  language.  The  database  structure  would  be  an  excellent 
project  for  a  thesis  student  in  the  Information  Systems  curriculum.  If  students  from  both 
the  Computer  Science  and  Information  Systems  curricula  could  be  encouraged  to  work 
together,  the  final  product  would  be  valuable  to  a  number  of  Navy  commands. 

D.  RECOMMENDATIONS 

From  numerous  conversations  with  former  and  current  Strike  Operations  and 
Assistant  Strike  Operations  Officers,  it  is  apparent  that  a  major  portion  of  the  airplan 


51 


production  problem  is  not  its  actual  construction.  Often,  it  is  the  interactions  throughout 
the  ship,  airwing  and  battlegroup  that  force  the  airplan  to  be  published  at  late  hours. 
Examples  of  such  factors  are  changes  in  forecasted  weather  or  an  unforeseen  loss  of 
assets  (  aircraft  down  for  maintenance  ).  These  interactions  must  be  dealt  with 
individually  and  prioritized.  In  most  cases,  their  impact  can  be  minimized  or  eliminated. 
For  any  automation  process  to  have  a  noticeable  impact  on  the  publish  time  of  the 
airplan,  the  process  itself  must  be  revised  to  some  extent. 

Throughout  the  day,  numerous  inputs  are  made  that  force  changes  to  the  next  day’s 
flight  operations.  The  changes  come  from  many  areas  as  discussed  in  Chapter  I.  The 
impact  of  the  changes  can  vary  from  minor  mission  changes  to  major  restructuring  of 
flight  operations  for  the  next  day.  The  major  changes  are  for  the  most  part 
uncontrollable.  They  usually  reflect  a  change  in  battlegroup  tasking  either  by  the 
battlegroup  commander  or  fleet  commander.  Revised  tasking  can  be  promulgated  at  any 
time  and  is  generally  accepted  as  the  nature  of  the  business.  These  problems  must  be 
addressed  at  a  level  much  higher  than  will  be  impacted  by  this  thesis. 

The  changes  that  can  be  controlled  are  the  ones  that  reflect  operations  internal  to 
the  battlegroup,  mainly,  combined  warfare  commanders  and  individual  squadron’s  needs 
or  wants.  Many  of  these  changes  can  be  minimized  by  establishing  guidelines  for 
changes  to  the  airplan;  i.e.  who  can  make  these  changes  and  when. 

1.  Airwing  Planning  Session 

It  is  recommended  that  squadron  representatives  meet  with  ASTKE  or  the 
Airwing  Operations  Officer  in  a  short  planning  session  for  the  next  day’s  events  after 
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warfare  commander  tasking  has  been  received.  A  meaningful  planning  session  would 
force  squadron  inputs  to  be  made  early  in  the  day.  Once  the  tasking  requirements  are 
met,  secondary  missions  could  be  added  to  allow  squadrons  to  accomplish  necessary 
training.  The  analysis  showed  only  27  percent  of  the  sorties  launched  were  multi-mission 
sorties.  While  some  missions  require  a  complete  sortie  to  accomplish,  many  can  be 
accomplished  as  secondary  missions  without  interfering  noticeably  with  the  primary 
mission. 

2.  Limit  Change  Opportunities 

Another  recommendation  is  to  set  a  deadline  when  all  routine  airwing  aiiplan 
changes  must  be  made.  The  intent  is  to  force  squadron  operations  officers  to  make  their 
changes  earlier  in  the  day  and  to  reduce  the  number  of  unnecessary  changes. 

Limiting  the  ability  to  make  changes  to  the  airplan  throughout  the  day  could 
be  detrimental  to  the  quality  of  the  final  product.  If  legitimate  changes  are  suppressed 
for  the  sake  of  publishing  the  airplan  at  an  earlier  time,  the  airplan  will  not  reflect  what 
will  actually  happen.  The  changes  will  be  made  during  execution  and  what  is  actually 
flown  will  not  reflect  what  was  scheduled.  If  the  recommendations  stated  earlier  are 
implemented,  this  problem  must  be  watched  for  and  handled  carefully. 
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APPENDIX  A  -  LIST  OF  MISSION  AREA  ACRONYMS 

•  ACM  Air  Combat  Maneuvers. 

•  AEW  Airborne  Early  Warning. 

•  AIC  Air  Intercept  Control. 

•  ASW  Anti  Submarine  Warfare. 

•  BMB  Bombing. 

•  CAP  Combat  Air  Patrol. 

•  CQ  Carrier  Qualification. 

•  DACT/M  Dissimilar  Air  Combat  Maneuvers/Training. 

•  ESM  Electronic  Support  Measures. 

•  EX  Exercise  (Any  Type). 

•  FCF  Functional  Check  Flight,  Post  Maintenance  Checkflight. 

•  LWLVL  Low  Level  Navigation. 

•  MAS  Maritime  Air  Superiority  (Long  Range  CAP). 

•  MTNK  Mission  Tanker. 

•  NAV  Navigation. 

•  NVG  Night  Vision  Goggles. 

•  SSC  Surface  Search  and  Communication. 

•  TG/T  Touch  and  Go  then  Trap. 

•  TARPS  Tactical  Air  Reconnaissance  Pod. 
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•  TNK  Recovery  Tanker. 

•  SVCS  Services  Provided  to  Another  Asset. 

•  STK  Strike  (actual  or  simulated). 

•  YOYO  Launch  and  Recover  on  Same  Cycle. 

•  OTH  Other. 
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APPENDIX  B  -  ANALYSIS  TOOLS 


A.  QUATTRO  PRO  3.0  ANALYSIS  TOOLS 

Numerous  functions  and  macros  were  used  to  extract  data  from  each  of  the 
file  types  discussed  in  Chapter  III.  For  those  unfamiliar  with  the  spreadsheet 
environment  functions  are  mathematical  or  logical  functions  that  are  applied  to  a  cell 

or  block  of  cells  in  a  spreadsheet.  Macros  are  small  programs  written  in  a  language 
specific  to  the  software  applications  in  use.  Macros  call  menu  selections  or 
functions  when  they  are  activated.  Quattro  Pro  macros  are  activated  by  naming  a  macro 
in  one  of  a  number  of  ways.  All  macros  used  in  the  analysis  were  named  using  the 
\"letter"  option  in  Quattro  Pro.  The  macros  are  then  activated  by  depressing  the  ALT 
key  and  the  letter  name  simultaneously.  Some  of  the  macros  and  functions  used  in 
the  analysis  are  listed  below  for  further  use.  [Ref  6] 

1.  Mission  Selection 

This  function  was  used  to  extract  the  number  of  each  mission  type  for 
individual  sorties.  It  compares  the  primary  and  secondary  mission  columns  with  a 
column  header  it  returns  a  1  if  there  is  a  match,  a  0  if  not. 


@IF  (®EXACT($E2,K$1),  1  ,®IF(®ISSTRING($F2),®EXACT($F2,K$1),0)) 


The  next  function  was  used  to  gather  information  concerning  squadron 
statistics  from  the  OVERALL  file.  It  compares  the  column  header  with  the  squadron 
letter  cell.  It  returns  a  1  if  there  is  a  match,  a  0  if  not. 


@IF  (  @EXACT($E2,K$1),1,0) 


The  inner  product  or  dot  product  function  (®SUMPRODUCT(’COLr,’COL2’)  can  be 
used  on  the  resulting  column  of  ones  and  zeros  with  other  columns  yielding  the  number 
of  sorties  with  a  given  trait,  such  as: 

•  launch  or  recover  cycle. 

•  number  of  cycles  flown. 

•  number  of  aircraft  per  event. 


2.  DAILY  File  Modification  Macro 

The  following  macro  was  used  to  restructure  the  daily  airplan  files.  The 
structure  of  these  files,  as  originally  entered  into  the  database  was  not  readily  transferable 
to  airplan  format. 

{HOME} 

{/  Column;Insert}Al..Jl  ~ 

{HOME} (RIGHT  1}{;CATENATES  CALLSIGN  COMPONENTS} 
®STRING(K1 ,0)&L1&®STRING(M1 ,0)  ~ 

{/  BLOCK;COPY}Bl  - 
B2..B150- 
{HOME}  {RIGHT  1} 

{/  Block;Values}Bl..B150~ 

B1..B150~ 
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{;  JOINS  MULTIPLE  MISSIONS  TO  ONE  FIELD} 

{HOME} {RIGHT  5}{;MOVE  TO  CELL  FI} 

(g)IF((@ISSTRING(OI)MND/i'®ISSTRING(PI)),(01&","&Pl),OI)~ 

{/  Block;Copy}Fl-{;COPIES  JOINED  MISSIONS  TO  APPROPRIATE 
CELL} 

{;MOVES  INFORMATION  TO  APPROPRIATE  PLACES} 

F1..F150~ 

{HOME} {RIGHT  5}~ 

{/  BLOCK;VALUES}FI..F150~ 

FL.FISO- 

{HOME} 

{/  BLOCK;MOVE}N1..N150~ 

DL.DI50- 

{/  BLOCK;MOVE}QL.Q150- 
II. .1150- 

{/  BLOCK;MOVE}R1..R150- 
J1..J150- 


3.  Event  Transfer  Macro 

This  macro  was  used  in  transferring  the  events  from  the  DAILY  files  to  the 
airplan  templates.  A  slight  modification  to  this  macro  would  enable  copying  airplan 
information  from  airplan  to  DAILY  file  format. 


{/  Block;Copy}{;COPY  BLOCKS  TO  AIRPLAN  TEMPLATE  (\C)} 
{RIGHT  7}  - 

{NEXTWIN}{DOWN  6}{?} 


4.  Statistics  Gathering 

The  following  macro  creates  columns  for  gathering  information  on 
squadron  operations.  It  is  formatted  for  use  on  DAILY  files. 


{HOME} 

{/  Row;Insert} 
{HOME} 
{RIGHT  20} 
A{RIGHT} 
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B{RIGHT} 

C{RIGHT} 

D{RIGHT}{;FORMS  COLUMNS  FOR  EACH  SQN} 

E{RIGHT} 

F{RIGHT} 

G{RIGHT} 

H{RIGHT} 

{LEFT  8} 

{DOWN} 

®EXACT(U$1,$L2)~ 

{/  Block;  Copy}  ~ 

U2 

{?}- 

{?}{;USER  INTERACTION} 

A 

{RIGHT}B 

{RIGHT}C 

{RIGHT}D 

{RIGHT}E{;COPIES  COLUMN  HEADERS  AT  BOTTOM  OF  FILE} 

{RIGHT}F 

{RIGHT}G 

{RIGHT}H 

{LEFT  7} 


B.  QUATTRO  PRO  AIRPLAN  PRODUCTION  TOOLS 

1.  Recovery  Column  Reveal  and  Hide  Macros 

The  following  macros  are  used  to  reveal  and  hide  the  columns  used  in 
calculating  i  jcoveries  for  each  cycle. 

{/  Column;Hide}  ~  {right  7}  ~  {;HIDE  RECOVERY  COLUMN  (\H)} 

{/  Column;Display}  {right}  -  {right  8}  ~  {;REVEAL  RECOVERY 
COLUMN  (\R)} 
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2.  Line  Drawing  Macros 

The  following  three  macros  were  written  to  aide  ASTKE  in  altering  the 
airplan  templates  for  specific  tasking  or  if  an  airplan  is  being  composed  from  scratch. 
These  macros  not  only  draw  the  appropriate  lines  for  single,  double  and  triple  cycle 
sorties  they  also  place  the  appropriate  number  of  sorties  recovering  in  each 
recovery  column. 

{right  2}  -  {;SUBROUTINE  CALLED  BY  LINE  DRAWS} 

{FOR  C4,1,4,1,A2}  ~  {;SINGLE  CYCLE  LINE  DRAW  (ALT  S)} 
{LEFT  5}{/  BLOCK;COPY}~ 

{RIGHT  4}  ~ 


{•.DOUBLE  CYCLE  LINE  DRAW  (ALT  D)} 
{F0RD11,1,4,1,A2}~ 

{FOR  D12, 1,7,1, A18}- 
{LEFT  8}0- 

{LEFT  4}{/  BLOCK;COPY}~ 

{RIGHT  12}- 


V- {RIGHT}  ~{;SUBROUTINE  CALLED  BY  MULTI-CYCLE  LINE 
DRAWS} 

{;TRIPLE  CYCLE  LINE  DRAW  (ALT  T)} 

{FOR  D21,1,4,1,A2}- 
{FOR  D22,1,7,1,A18}- 
{FORD23,l,8,l,A18}~ 

{LEFT  8}0- 
{LEFT  8}0~ 

{LEFT  4}{/  BLOCK;COPY}  - 
{RIGHT  20}  - 
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APPENDIX  C  -  USER  GUIDE 


A.  INTRODUCTION 

The  following  is  designed  to  give  the  prospective  user  the  background  needed  to 
utilize  the  interactive  database  model  described  in  Chapter  IV.  Each  facet  of  the  model 
will  be  addressed.  This  appendix  along  with  Appendix  B  of  macros  and  functions  should 
be  enough  to  explain  the  workings  of  the  application  for  basic  use. 

The  application  uses  two  commercially  available  software  programs  Paradox  3.5 
and  Quattro  Pro  version  3.0  or  higher.  All  program  specific  menu  commands  in  this 
document  will  be  Quattro  Pro  commands.  Menu  commands  and  file  names  will  be  made 
in  all  capital  letters,  such  as  FILE/SAVE  and  MACROl.WQl.  Macro  commands  will 
be  preceded  by  ALT  then  the  letter  corresponding  to  the  named  macro,  such  as  ALT  A. 
This  is  how  macros  are  activated  in  Quattro  Pro.  If  another  spreadsheet  program  is 
being  used,  the  commands  will  be  different.  [Ref  5] 

The  general  flow  through  the  application  is  accomplished  first  in  Paradox  where 
the  user  selects  a  candidate  airplan  via  menu  driven  queries.  The  date  associated  with 
that  candidate  airplan  is  the  file  name  for  that  airplan  in  Quattro  Pro.  The  spreadsheet 
file  or  files  are  then  viewed  in  Quattro  Pro. 

Once  a  decision  is  made  on  which  of  the  templates  is  to  be  used  that  template 
should  be  copied  with  a  new  file  name  that  corresponds  to  the  date  of  the  new  airplan. 
This  is  accomplished  by  using  the  macro  ALT  Z.  It  is  important  to  copy  the  airplan 
prior  to  making  any  changes.  This  keeps  the  initial  database  constant  until  it  can  be 
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updated.  If  changes  are  made  to  the  template  airplans  the  database  queries  will  provide 
erroneous  information.  Each  aspect  of  the  application  will  be  addressed  separately. 

B.  Paradox  3.5 

The  Paradox  portion  of  the  application  is  menu  driven  queries  which  allow  the  user 
to  select  an  airplan  based  on  a  number  of  different  criteria.  The  menus  are  structured 
to  walk  the  user  through  the  selection  process.  A  diagram  of  the  menus  can  be  seen  in 
Figure  5.  The  menus  were  constructed  using  Paradox’s  Personal  Programmer  Feature. 
The  user  should  enter  Paradox  via  the  PPROG  directory  [Ref  7]. 

1.  Queries 

The  queries  defined  by  the  interactive  menu  selection  and  user  inputs  allow 
the  user  to  select  an  airplan  that  best  meets  the  expected  tasking  for  the  next  day. 
Choices  are  determined  by  the  inputs  commonly  made  at  the  beginning  of  airplan 
construction.  The  six  query  choices  are  structured  as  follows: 

•  Number  of  day  cycles  and  night  cycles. 

•  Number  of  total  cycles. 

•  Number  of  total  sorties. 

•  Number  of  night  sorties. 

•  Number  of  total  cycles  and  total  sorties. 

•  Day  cycles,  night  cycles  and  total  sorties. 
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Each  of  the  queries  returns  a  table  of  airplans  that  meet  the  desired  inputs.  Also  note, 
where  sorties  are  involved  the  constraints  are  maximums  but  in  determining  the  number 
of  cycles  the  numbers  must  be  exact  matches. 

2.  Mission  Distinction 

Along  with  the  date  for  each  of  the  airplans  are  a  number  of  mission  area 
percentages.  These  percentages  reflect  the  number  of  sorties  on  that  airplan  that  have 
that  mission  as  a  primary  qt  secondary  mission.  This  gives  the  scheduler  another  method 
of  narrowing  the  possibilities.  Once  a  candidate  airplan  has  been  chosen,  it  can  be  found 
in  Quattro  Pro  spreadsheet  format  with  file  name  MMDDYY.WQl. 

C.  Quattro  Pro 

1.  Macro  File 

The  aiiplan  files  the  scheduler  will  be  using  are  saved  as  Quattro  Pro 
worksheets.  Upon  entering  the  Quattro  Pro  environment  the  MACRO.WQl  file  should 
be  opened.  This  file  contains  the  macros  used  to  aid  the  production  process.  The 
MACRO.WQl  file  is  a  Quattro  Pro  macro  library.  When  a  macro  is  activated  Quattro 
Pro  first  looks  in  that  spreadsheet  for  the  commands.  If  they  are  not  present  there, 
Quattro  Pro  looks  for  an  open  macro  library.  If  this  file  is  not  open  the  macros  will  not 
run.  [Ref  6] 

2.  Daily  Airplan  File 

The  file  names  for  the  airplan  worksheets  are  of  the  form  MMDDYY.WQl. 
As  suggested  earlier  the  original  airplan  files  should  not  be  altered.  Neither  should  the 
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blank  templates.  The  file  should  be  opened  and  viewed  to  see  if  the  airplan  meets  the 
necessary  requirements  for  the  next  day.  Once  an  airplan  template  is  selected  the  ALT 
Z  macro  should  be  used.  Once  again,  this  is  to  maintain  integrity  of  the  database 
queries.  Once  this  is  done,  the  file  has  a  new  name  and  can  then  be  altered. 

3.  Hidden  Columns 

Prior  to  changing  the  airplan,  there  are  a  number  of  hidden  columns  that  need 
to  be  revealed.  This  is  accomplished  by  positioning  the  cell  pointer  on  the  left  side  of 
the  first  cycle  vertical  line,  as  seen  in  Figure  6.  From  this  position  use  the  macro 
command  ALT  R  (REVEAL)  repeatedly  until  all  hidden  columns  in  the  airplan  have  been 
revealed.  The  hidden  columns  contain  an  H  in  the  cycle  row  to  remind  the  user  they 
need  to  be  hidden  when  the  airplan  is  complete.  The  columns  are  hidden  by  placing  the 
cell  pointer  in  the  first  column  to  be  hidden  and  using  the  ALT  H  (HIDE)  macro 
repeatedly  until  all  recovery  columns  are  hidden.  The  hidden  columns  contain  the 
number  of  aircraft  recovering  in  a  particular  cycle,  hiding  them  is  strictly  for  aesthetics. 
Placing  the  number  of  aircraft  recovering  in  these  columns  allows  the  spreadsheet 
program  to  calculate  the  sortie  totals  at  the  bottom  of  the  airplan. 

4.  Modification 

With  the  recovery  columns  revealed,  the  airplan  can  be  altered  to  suit  the 
next  day’s  tasking.  It  is  imperative,  for  calculation  purposes,  that  the  number  of  sorties 
launching  and  recovering  be  placed  in  the  correct  column.  This  is  easily  determined 
since  all  columns  in  the  airplan  templates  are  defaulted  to  contain  labels  except  the 
quantity  and  recovery  columns.  Whether  a  column  is  considered  a  label  or  not  can  be 
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seen  in  the  input  line  at  the  top  of  the  spreadsheet.  The  word  Label  will  be  the  first 
word  in  the  input  line  in  all  columns  except  those  used  in  calculations.  The  sortie  counts 
are  made  by  using  a  series  of  named  blocks.  The  general  layout  of  these  blocks  is  given 
in  Figure  6.  Launch  and  recovery  totals  are  calculated  by  summing  over  the  named 
blocks.  If  letters  appear  in  these  blocks  an  ERR  message  will  appear  where  the  total 
should  be. 

5.  Sortie  Lines 

If  an  airplan  is  begun  from  one  of  the  provided  blank  templates,  or  major 
revisions  are  made  to  an  existing  airplan,  there  are  three  other  macros  designed  to  speed 
up  the  process.  ALT  S,  ALT  D,  and  ALT  T  are  line  drawing  macros  in  MACRO. WQl 
for  single,  double  and  triple  cycle  sorties  respectively.  They  are  utilized  by  placing  the 
cell  pointer  in  the  column  preceding  the  callsign  and  activating  the  appropriate  macro  for 
the  duration  of  the  sortie.  The  lines  are  drawn  for  the  correct  duration  and  the  number 
present  in  the  quantity  column  is  placed  in  the  appropriate  recovery  column. 
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